NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/1041

Internet Message Format | 1996-08-05 | 4.7 KB

Path: Rezonet.net!news
From: [e-mail] (Ray Dunn)
Newsgroups: comp.lang.c
Subject: Re: Problem with stringcopy
Date: 11 Jan 1996 03:19:48 GMT
Organization: Ultimate Technographics Inc.
Distribution: world
Message-ID: <4d1vkk$[e-mail]>
References: <4clguu$[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: 204.19.230.7
Mime-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
X-Newsreader: WinVN 0.99.7

We all really made a meal of this string copy question.

All the tools you need for manipulating strings in 'C' are there, but
sometimes they are awkward to use, and it's sometimes best to write
your own routines to do specifically what you want.

The original question said:

>How do i do a partial stringcopy i.e. copy from a specific position in
>a string and a certain numbers of bytes. I am looking for a function
>like target = Stringcopy(source, startpos, length)

This seems simple on the surface, but it actually omitted more than it
said, i.e. how to handle all the pathalogical cases.

If the number of characters to be copied from the source string is
known, that implies that the terminating '\0' probably doesn't come
into it, and assuming that it's known to be overwriting _existing_
characters in the target string, then there are no pathalogical cases,
and the solution is just a simple memcpy:

    memcpy(target + target_posn, source + source_posn, length);

[as Lawrence pointed out several times, the use of strncpy here is
probably not the best choice, even though it works perfectly well].

If you want the target to be *terminated* after the copied characters,
you'd have to add the line:

    *(target + target_posn + length) = '\0';

If we don't want that though, and there is a posibility that the copied
characters "run-off" the end of the target string, it gets a little
more complicated, because again memcpy is not going to terminate the
new target string correctly, and (assuming the target has enough space
for the lengthened string) we'd have to write something like:

    target_room = strlen(target + target_posn);
    memcpy(target + target_posn, source + source_posn, length);
    if (target_room < length)
      *(target + target_posn + length) = '\0';

Now, if there also may not be length characters in the source string at
source_posn, we have to decide what the functionality should be.
Presumably we dont want the target string to be terminated at the end
of the copied characters, so let's say we just copy as many characters
as we can:

    source_available = strlen(source + source_posn);
    if (source_available < length)
    length = source_available;

    target_room = strlen(target + target_posn);
    memcpy(target + target_posn, source + source_posn, length);
    if (target_room < length)
        *(target + target_posn + length) = '\0';

It may also be necessary to check that target_posn and source_posn are
not greater than the lengths of the corresponding strings, and have a
rule as to what happens in this case - do nothing, let's say.

    source_length = strlen(source);
    if (source_length > source_posn)
    {
      if (source_length - source_posn < length)
    length = source_length - source_posn;

      target_length = strlen(target);
      if (target_length >= target_posn)
      {
        memcpy(target + target_posn, source + source_posn, length);
        if (target_posn + length > target_length)
          *(target + target_posn + length) = '\0';
      }
    }

[there may be errors in this code, I just whacked it in, some of the
tests may be one out]

Because two strlen's and a memcpy have been required, and the logic is
quite complicated, at this point I'd give serious consideration to
writing a general purpose function which did it's own scanning of the
strings.

One case where the standard functions are particularly inefficient is
when you're doing several sequential strcat's.  Strcat has first to
scan through the whole destination string to find its end, so a
homegrown function to return the *end* of the new concatenated string
is worth considering, and are not necessarily slower than using
library functions.  At one point in the MS 'C' libraries (up to 5.1 at
least), strcmp and strstr were doing strlen's on both the strings prior
to the compare scan - I found this out when I used these functions to
repetitively scan very large file buffers - needless to say I wrote my
own routines.

...and yes, string manipulation is much easier in BASIC, but I wouldn't
use that as a reason to program in BASIC rather than 'C'.
--
Ray Dunn (opinions are my own) | Phone: [phone]
Montreal                       | Phax : [phone]
[e-mail]          | Home : [phone]